home *** CD-ROM | disk | FTP | other *** search
/ QRZ! Ham Radio 8 / QRZ Ham Radio Callsign Database - Volume 8.iso / pc / files / p_misc / netconf.arc / TEXNET.003 < prev    next >
Encoding:
Text File  |  1988-12-17  |  10.0 KB  |  185 lines
  1. [ Note: This series of articles was found on Compuserve and downloaded 
  2.   from HAMNET there on 21 July 1985 by Dwight Ernest KA2CNN 70210,523. ]
  3.  
  4.                    An Introduction to Networks
  5.                              part 3
  6.                      by T.C. McDermott, N5EG
  7.                        networks SIG, TPRS
  8.  
  9.      The last article discussed End-to-end Vs. Hop-to-hop methods of
  10. acknowledge, and the attendant advantages of each.  As you may recall,
  11. one of the disadvantages of the HHA was the possibility of a network
  12. failure still allowing the sender to have been acked for data that may
  13. not, in fact, have been received.
  14.  
  15.      Generally, this is not a problem.  If communications fails along a
  16. path we naturally tend to want a re-transmission of the entire contents
  17. of whatever file we may have been sending.  If we happened to be in the
  18. keyboard mode, then since the communications fialed, we cannot continue
  19. to send anyway.  Thridly, our TNC's do not tell us how much data they
  20. have in their transmit buffers that has not been acknowledged, so the
  21. HHA network really doesn't differ from the types of responses that we
  22. are used to from the TNC - LAN system.
  23.  
  24.      If we must guarantee the absolute integrity of a file transfer,
  25. then we should implement some type of block numbering and sequencing
  26. program that controls the file transfer process.  In essence, something
  27. like the MODEM7 protocol tacked on top of our existing TNC protocol
  28. would guarantee the complete integrity of files transfered.  We would
  29. probably want to add onto the MODEM7 system a little bit, perhaps to
  30. record what was and was not sucessfully transfered, and perhaps a method
  31. of automatically re-establishing the connection to the other station,
  32. and continuing with the transfer process until it is sucessfully
  33. completed, and then tearing down the connection.
  34.  
  35.      This additional program that we would run on each of our end-user
  36. computers (both sender and receiver) is the LAYER 4 of the OSI model -
  37. the transport layer.  Since the network we are talking about
  38. constructing is thus releived of absolute ACK integrity by the presence
  39. of this additional program (in those rare instances where it is really
  40. needed) then our netork is only restricted to providing a reasonable
  41. guarantee of integrity, perhaps guaranteeing that packets arrive in the
  42. correct sequence, and without bit errors.  Thus with an emphasis on the
  43. HHA VS. the EEA methods, we have decided to build a network that
  44. optimizes throughput and response, allowing for a layer 4 program in the
  45. event it is needed, but not sacrificing the performance of the network
  46. for the vast majority of the uses of the network.  This trade-off is
  47. usually described as a speed-integrity tradeoff in the literature.
  48.  
  49.      Now that a decision has been reached on the desired attributes of
  50. the network, that is speed, and simplicity, we may concentrate on one
  51. final interface aspect, and that is how the LAN (i.e. the TAPR TNC's)
  52. are to interface and establish connection through the network.  This
  53. linkage is the peer communication between two layer 3 processes that is
  54. described by Tannenbaum [1].
  55.  
  56.      In the 7-layer OSI model, subnet communication (that is
  57. communication through a network) is established between two layer 3
  58. processes - that is, the TAPR TNC AX.25 mode, and the network entrance
  59. and exit layers.  Although AX.25 is sometimes discussed as a layer 2
  60. protocol, in the LAN application it is really a layer 3 process.  It
  61. establishes, communicates, and terminates, and thus it is a layer 3
  62. process.  Similarly the network, upon command, will establish,
  63. communicate, and terminate, thus it also is performing a layer 3
  64. function.
  65.  
  66.      Why the concern about which layers to call each other?  Because it
  67. is desirable that the TNC's be able to use the network without any
  68. modification.  Thus the network must be compatible to the way that the
  69. TNC establishes, maintains, and terminates connections, since the
  70. network must establish, maintain, and terminate connections to or from
  71. TNC's and itself.  We are faced with the choices as to how the TNC and
  72. the network can talk with one another.
  73.  
  74.      One method of network interface is to assume that the network is
  75. transparent, that is it looks like a digipeater.  Then you would use
  76. your TNC as though the network were a single digipeater (even though it
  77. might have many hops, it would appear to the TNC as one digipeater).
  78.  
  79.      Another method is to treat the network as a spearate LAN address.
  80. This is, you would connect to the network.  Then the network would
  81. engage in an interactive session with you regarding the type of service
  82. that you needed, that is, who you wanted to talk to, and how to get
  83. through the network to that place.  Once the network computer was
  84. satisfied, it would then engage in comunications between the endpoints.
  85. Your TNC would think it was connected to the network, not to your actual
  86. destination station.
  87.  
  88.      Each of these connection methods has advantages and disadvantages.
  89. We will discuss some of them here.
  90.  
  91.      The digipeater-emulation method is a very natural method to use,
  92. because the connection method is familiar to all of the TNC users.  Let
  93. us establish the following scenario: WD0ETZ in Carrollton wishes to
  94. communicate with WD5GAZ in Houston.  WD0ETZ knows that this distance
  95. will require the use of the network.  So WD0ETZ proceeds as follows...
  96.  
  97.      Connect WD5GAZ VIA DALLAS
  98.  
  99.      This seems simple enough, but some interesting problems crop up
  100. almost immediately.  How does the network know where to find WD5GAZ?
  101. What path is required to get there?  WD0ETZ's TNC is going to want to
  102. see ACK's from WD5GAZ, not from DALLAS.
  103.  
  104.      First problems first.  One way for the network to know how to find
  105. WD5GAZ is for it to keep tables in all of the sites of each and every
  106. network user.  This is really not practical in an amateur environment
  107. because hams move, come, and go, and even change callsigns, and with
  108. very many users, it takes a lot of manual intervention to keep the
  109. tables current.  It also takes a lot of computer power in the network to
  110. store and route messages based upon these tables.  In the event of a
  111. network crash, the tables would have to be reloaded, etc.  A simpler way
  112. would be for the originator, in this case WD0ETZ, to specify the network
  113. "hop-off" point, that is, the location in the network where WD5GAZ is
  114. likely to be found.  For example:
  115.  
  116.      Connect WD5GAZ VIA DALLAS,HOUSTON
  117.  
  118.      Now the network knows that the entry point is this network (which
  119. is "DALLAS", the one hearing WD0ETZ) and the exit point is HOUSTON.
  120. Perhaps different types of names would be chosen for network nodes.
  121. Grid-squares and major city names seem to be two obvious choices.  What
  122. about the route to take to get along the network?  There is an
  123. incomplete but simple answer to this question - make a linear network
  124. (or a simple variant of linear).  A linear network is one where the
  125. network is basically a straight line.  Thus there is by definition only
  126. one path between any two points.  A few other questions.  What if WD5GAZ
  127. is not within range of the HOUSTON node, but perhaps within range of a
  128. station that is near to the node - for example suppose that WA5AAA is
  129. between the HOUSTON node and WD5GAZ.  Then...
  130.  
  131.      Connect WD5GAZ VIA DALLAS,HOUSTON,WA5AAA
  132.  
  133.      What if WD0ETZ is not within range of the DALLAS node, but is
  134. within range of WB5QNG, who is within range of DALLAS ?
  135.  
  136.      Connect WD5GAZ VIA WB5QNG,DALLAS,HOUSTON,WA5AAA
  137.  
  138.      Well, the addressing would work.  But the network entry point has
  139. to do some strange things to the address field.  Remember in the HHA
  140. scheme it would be the address DALLAS that is actually ACKing WD0ETZ,
  141. and not WD5GAZ that would be ACKing WD0ETZ, so the network node has to
  142. play "fast-and-loose" with the address headers in the digipeat field.
  143.  
  144.      The other method is fairly straight forward.  The user connects to
  145. the network, and then enters an interactive Q & A session:
  146.  
  147.      Connect DALLAS
  148.      Welcome to TEXNET - DALLAS node.
  149.      There are currently 4 other users connected to DALLAS.
  150.      Enter destination callsign ? ( WD5GAZ would be entered here)
  151.      Enter network exit node    ? ( HOUSTON would be entered)
  152.      Enter destination digipeaters ? (WA5AAA would be entered)
  153.      CONNECTION ESTABLISHED - PROCEED
  154.  
  155.      Notice one thing in the above scenario: more than one station may
  156. be connected to the network node entry and exit points.  This is
  157. something that is a little foreign to the AX.25 protocol, that is
  158. MULTIPLE VIRTUAL CHANNELS to a single TNC. In this case it is still
  159. compatible with AX.25 since both source and destinations callsigns are
  160. part of the AX.25 standard.  Only the network nodes have to have this
  161. special property of having to be connected to several different stations
  162. simultaneously - thus the AX.25 code for these controllers is a little
  163. different from a normal implementation.  But only the network requires
  164. these special TNC's (actually they are built into the node controller,
  165. and aren't identifable as a separate device).
  166.  
  167.      The reason that the network should allow for multiple virtual
  168. channels is to allow multiple people to simultaneously use the network.
  169. Since we will put high-speed radios in the network between nodes, we
  170. should take advantage of the bandwidth available.
  171.  
  172.      At this point we will not go into the network protocol required to
  173. implement these connection schemes, that "play-games" with the address
  174. header fields to keep our TNC's happy, and that perform the HHA transfer
  175. between the network nodes, do flow control inside the network, and route
  176. the signal to the destination.  That is the subject of another article.
  177.  
  178.      The next article will deal with the type of hardware that will be
  179. required to support this concept of a network, and it turns out to be
  180. surprisingly modest.  There are some other concerns about capacity,
  181. response time, channel utilization, reliability, and remote network
  182. "resuscitation" (in the event of software failure) that will also be
  183. addressed in part 4 of this series.
  184. 
  185.